Здравствуйте!
В системе будут около 160 фанкойлов Daikin к которым можно подключиться только по модбас.
Пару десятков приточек Ned с контроллером Carel (у них вроде любые коммуникации возможны).
С десяток чиллеров Daikin (Microtech III - тоже весь набор коммуникаций)
Котельная с железкой от Viessman.
Около 30 вытяжек, их тоже надо вытянуть к диспетчеру.
Резерв 30 точек.
Диспетчерская пока одна, но желание может и поменяться.
По большому счету каждый узел работает сам по себе, и друг с другом не общается, отдает только данные наверх.
Заказчик ничего по теме не говорит, ему надо чтоб было надежно и удобно, ну и не хуже чем у других.
Все данные видеть у диспетчера - считаю лишнее, поэтому в среднем по 10 переменных на точку думаю достаточно.
Из за неопытности не могу определиться в какую сторону двигаться, LON, Bacnet, KNX?
Было предложение построить сетку Modbus tcp, как вам вариант?

Правильный вариант. У Carel еще может стоять модуль SNMP, но чтобы он передавал данные, необходимо это учитывать в программе. (с Modbus возможно таже ситуация, не помню). И если у вас нет программ на них и там нет разрешения на передачу данных, то вы встряли )

KNX явно не в тему - не для этого он.
Лично я максимально использовал бы Modbus.
Какую SCADA-систему будете использовать?

На Carel есть список переменных, и платы PCOS004850 в Modbus Rtu недорогие, а до скады еще не дошли.

Модбас+ОРС сервер на него и крутите как хотите - доставайте для диспетчера только требуемые данные, СКАДы все нормально с ОРС серверами находят понимание.
Для примера :
http://www.owen.ru/catalog/modbus_opc_dde_server/opisanie

Присматриваемся к железкам от МОХА, шлюзы Rtu/Tcp Mgate MB3270I и модули ввода/вывода IOLogic E1214.
Кто пользовался, скажите можно ли настроить скажем с десяток шлюзов чтобы они опрашивали слэйвов на стороне Rtu и в случае смены данных отсылали их по Modbus/Tcp на тот же лектус, или постоянно сканить все слэйвы, а это около 2000 регистров, не много ли для Modbus/Tcp, может организовать контроллеры? Второй вопрос как будет вести себя модуль ввода /вывода когда допустим нет связи по Tcp, сохраняет ли он значения выходов, или тоже здесь использовать контроллер?

Опрашивать придется постоянно. Modbus протокол простой, но деревянный - мастер спросил, слейв ответил.
Если стоит задача управления, то лучше ставить ПЛК. Крутить логику в скаде не надежно.

Вы в первую очередь "географию" прикиньте - как у вас кабельные линии пойдут, а то знаете 1,2 км 485 может не хватить все 32 слэйва обвязать, и понадобится вам шлюзов ставить больше.
Архитектура...
Тут вопрос сложный и вариантов полно, делайте как вам привычнее, как вы уже делали - так лучше всего.
Лично я предпочитаю перед АРМом иметь контроллер (или несколько) , которые опросами занимаются и информ.пакет на СКАДу формируют (сравнивают состояния изменения входов), да собственные архивы ведут.
Но это наследие работы с S5, сталкивался и с реализацией шлюзы-АРМ - тоже нормально работает.
Время тут не так важно - у вас система контроллируемая инерционная , даже полное обновление 1 раз в несколько минут нормально будет.


Вот я такое же ощущение на уровне спинного мозга имею, а объяснить почему так - не могу.
Вроде и надёжность ПК и быстродействие сейчас на уровне, а всё равно что-то прям мешает...

В том и дело что не делали еще, опыта по теме мало, не хочется делать необдуманные шаги.
ССылаясь на описание модуля ввода/вывода IOLogic E1214 он может передавать данные по Tcp только когда они меняются, еще у него ограничение 256 тэгов. Это получается если у меня 30 устройств на 485, по 10 переменных на каждое, плюс свои входа/выхода, то эта железка уже не справляется?

Скажите, а какие плюсы и минусы есть у модбас/тсп и модбас поверх тсп, что удобнее для опс сервера?

Модбас поверх TCP предполагает работу с компортом.
Но в по большому счету все одинаково.
Зачем вам OPC? С модбасом большинство скад напрямую работают нормально

На сколько понял RTU у них в комплекте, а для TCP OPC нужен, но несколько другое хотелось развеять, выбираем оборудование сварганить сетку. И здесь кое что непонятно, в мануалах на шлюзы MOXA пишут что они в качестве слэйва TCP могут обрабатывать запросы 16 клиентов, интересно а 16 запросов одного клиента (скады) могут? Да и сами скады могут по Modbus TCP вести этот "одновременный" опрос?
Есть шлюзы которые себе в память складывают, но почему то они только в Ethernet/ip, подозреваю что модбасом тут уже пахнет?

Уважаемые! Чисто теоретический вопрос. имеющий практическое значение. Следует ли использовать контроллеры с RTU, представляющие IP узел? Потому как из года в год количество проектируемых на объекте узлов растет, а LON, Bacnet, KNX хороши, но для мелких объектов и дороговаты. Просто отпишите свои соображения.

Увы, не могу вам подсказать конкретно по плюсам и минусам RTU c IP.
Я бы пошёл по пути увеличения количества информационных сетей (н-р, объединённых по функциональному или территориальному признаку) с отдельными серверами (опрос и хранение) и последующим сведением в единый АРМ.

двигайтесь в сторону Hawk от Centraline и Arena AX. Более удобной вещи для мультипротокльной интеграции я не встречал.

Почитал про Hawk, все хорошо, и входа/выхода, 485 на борту и другие варианты интеграции, и контроллер, и сам всякие тренды ведет. Но, в самом (по крайней мере для меня) проблемном месте - выводе данных наверх они используют свой протокол и скаду, этим они привязывают к себе. А хотелось бы иметь более просторное поле для выбора и самой железки и способа реализации.

это заблуждение. Да там свой прямой протокол для своей скады АХ. Но он просто для простоты вытаскивания контроллеров в СКАДу, ну типа плагэндплей. Никто вам не мешает добавлять их в любую другую скаду по бакнетайпи, модбасу рту или айпи. За лон не скажу, лично не пробовал, надо у производителей интересоваться.

К тому же на хоках всегда можно разместить графику внутри контроллера и тупо подключаться к ним через браузер без лишних скад. Ну и в прайсе у централайн есть лицензия на скаду на один Hawk.

А на эти Hawkи какие нить доки на руском бывают?